Found in

• Nightly 110.0a1

Affected versions

• Nightly 110.0a1

Tested platforms

• Affected platforms: Windows 10, Windows 11, Windows 7
• Unaffected platforms: macOS, Linux

Preconditions

• Have Google Drive for desktop (https://www.google.com/drive/download/) or TortoiseGit (https://tortoisegit.org/) installed.

Steps to reproduce

1. Visit about:third-party
2. Hit CTRL + O and dismiss the File Menu
3. Click the black minus icon for any DLL showing in the list eg. drivefsext.dll
4. Click Restart now
5. Refresh the page
6. Click the red X icon
7. Click Restart Later
8. Refresh the about page

Expected result

• The DLL from step 3 has the unblocked icon (black minus icon).

Actual result

• The DLL from step 3 has the same blocked icon (red X icon). This

Regression range

• Not a regression since this also exists in a build before this feature was turned on (2022-12-31), but it worked a bit differently by having the "Blocked by Nightly" icon instead.

Additional notes

• This is also reproducible while in troubleshoot mode or by having the --disableDynamicBlocklist
• If I have all the dlls displayed and block one dll and hit restart later + refresh about page, the dll will have the icon changed to the correct one (a restart is still needed for the action to take place but the icon is changed correctly).

Nice catch!

Sigh, this is another inconsistency between what is blocked during this run of Firefox and what will be blocked during the next run of Firefox. It shouldn't be too hard to fix, and I think it would be worth uplifting to Beta, as it can lead to a pretty confusing situation for users where they think they have blocked something but they have not. (or vice versa)

Previously if a module was on the dynamic blocklist but had not attempted to load in this run of Firefox, we would always show it as blocked when loading the about:third-party page. This meant that if the user unblocked the module and then reloaded the page, it would show up as blocked, when the intended behavior is to show it as not blocked. (since this is what will happen after Firefox restarts)

The fix is to use the same mechanism that we do with modules that have attempted to load: call AboutThirdParty.lookupModuleType() to determine whether it was blocked on launch, and whether it will be blocked the next time Firefox restarts. I went ahead and also added a call to see whether the module was involved in a previous crash, and added that icon as well.

I intend to uplift this to Beta, as this can lead to a pretty confusing situation for users where they think they have blocked something but they have not. (or vice versa)

https://hg.mozilla.org/mozilla-central/rev/84b37de7aa0f

The patch landed in nightly and beta is affected.
:gstoll, is this bug important enough to require an uplift?

• If yes, please nominate the patch for beta approval.
• If no, please set status-firefox110 to wontfix.

For more information, please visit auto_nag documentation.

Confirming that this is now fixed on the latest Nightly 111.0a1 on Windows 10, 11 and 7.

Comment on attachment 9312694 [details]
Bug 1810539 - show correct blocked status after reloading about:third-party r=yjuglaret,gijs

Beta/Release Uplift Approval Request

• User impact if declined: Users can get into a confusing state if they block or unblock a DLL, don't immediately restart, then reload about:third-party (the icons will be backwards from what they should be)
• Is this code covered by automated tests?: No
• Has the fix been verified in Nightly?: Yes
• Needs manual test from QE?: Yes
• If yes, steps to reproduce:
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): smallish change to the about:third-party JS code; fix has already been verified on nightly
• String changes made/needed: no
• Is Android affected?: No

Comment on attachment 9312694 [details]
Bug 1810539 - show correct blocked status after reloading about:third-party r=yjuglaret,gijs

Approved for 110 beta 4, thanks.

https://hg.mozilla.org/releases/mozilla-beta/rev/dbf4cdf3d91c

I verified that using latest Beta 110.0b4 on Windows 10, 11 and 7 this is fixed.